home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / Re Kudos and Q's.2 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.9 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Kudos and Q's
  2. Sent:        5/28/96 11:03 AM
  3. Received:    5/28/96 11:31 AM
  4. From:        Troy Gaul, tgaul@apple.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >>The first more pragmatic question is: I don't really care about the "S",
  9. >>".xh" and ".xih" files that are the output of the SOM compiler, do I?  This
  10. >>is just stuff to placate the linker and bind my calls, right?
  11. >>
  12. >.xh and .xih are just like .h files. You need the client of your library 
  13. >to include the .xh file in order to call methods of your library. I am 
  14. >not the best expert in SOM. I'll let someone else explain that to you.
  15.  
  16. Actually, the .xh file is like a .h file.  It contains the C++ mapping of 
  17. the classes/methods/etc. in the .idl file so they can be called from C++ 
  18. (they don't call it simply .h because this is used for the C binding).  
  19. You'll note that whenever a non-utility OpenDoc file is included, you're 
  20. including the .xh file.
  21.  
  22. The .xih file is actually an 'implementation' file.  It contains the 
  23. SOM-goo that the linker needs.  Generally, you #include the .xih file 
  24. from the main .cpp file for the SOM class (the .cpp file is also 
  25. generated by somc, and then you fill in the methods).  For a SOM class to 
  26. be accessible from outside its own shared libarary, you need to export 
  27. the xxxClassData symbol that is defined in the .xih file.  Also, on the 
  28. Mac, for a SOM object to be created by name, you need to include a 
  29. properly formatted cfrg resource that lists the fully-qualified name of 
  30. the class as one of the members.
  31.  
  32. If you wish to distribute an interface to your SOM class to other people, 
  33. you generally include the .idl, .xh, and optionally .h files.  You also 
  34. need to include a stub shared library for the client to link against.  
  35. However, even if they don't have your .xh, it's possible for them to 
  36. generate their own for the language of their choice.  If you're using a 
  37. direct-to-SOM compiler, I think all you need is the .idl (and the stub 
  38. library).
  39.  
  40. >>The second more pragmatic question is: Metrowerks CW9 binds ".idl" with the
  41. >>"SOMObjects TS" CodeWarrior plugin, does this mean the Finance SOM example
  42. >>could be reworked so it doesn't need the MPW make file (nb, the MPW
  43. >>'script' file)?
  44. >
  45. >Yes, you just need Toolserver.
  46.  
  47. Of course, you need to make sure that ToolServer is set up correctly, and 
  48. that you've put the standard SOM .idl include folder into your 
  49. CodeWarrior search path.
  50.  
  51. If you need any more information about the SOMobjects TS plug-in, let me 
  52. know.  I wrote it (based on the ToolFrontEnd code from Develop).
  53.  
  54. _troy
  55.  
  56. ......................................................................
  57.  Troy Gaul                                            tgaul@apple.com
  58.  Apple Computer, Inc.                    OpenDoc Added Value Products
  59. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
  60.